Generating conversation threads for a unified messaging system

ABSTRACT

Methods and systems directed to assigning individual messages and call log data into an aggregated conversation thread on both client and server devices for a user interface having a conversations view including all the communications a given users has with his or her contacts across multiple communication means and protocols. Messages between a user and a particular contact are threaded together, regardless of their format or protocol in order to provide the user with a quick history of all communications with his or her contacts.

TECHNICAL FIELD

The present disclosure relates generally to wireless messagetransmission.

BACKGROUND

The advent of social networking, instant messaging, and ubiquitouswireless data networks allows individuals to select from a plurality ofmethods to communicate with their contacts. In the past, communicationsbetween individuals were limited to physical mail, wired telephones,fax, and wireless telephones. However, with the expansion of theInternet, coupled with mobile devices capable of maintaining a dataconnection to the Internet, users may select from a plethora ofcommunications means, such as: cellular phone calls, e-mail to multipleaccounts, multiple instant messaging protocols, twitter messages,voice-over-IP (VoIP) calls, video chats, SMS and MMS messages, socialnetworking messages, voicemail, push-to-talk (PTT), and dedicatednotification-based message clients such as the BLACKBERRY MESSENGER ANDKIK MESSENGER. Typically, users are less concerned by the actualcommunications method used with their contacts, and more concerned withthe content of the communication and to or from whom it was conveyed.

Mobile devices such as mobile phones, tablets, and personal computersoften communicate through wireless networks provided by cellularcarriers. Modern 3G and 4G networks, both CMDA2000-based and GPRS-based,permit simultaneous access of wireless data through the packet-switchedportion of its wireless cellular network and voice data through thecircuit-switched portion of its wireless cellular network. Modernwireless cellular networks permit simultaneous communication through thepacket-switched data portion of their networks and through their shortmessage service (SMS) channels. Additionally, wireless devices may alsocommunicate through one or more wireless LANs, such as 802.11 WiFinetworks. Based on service coverage and the location of a wirelessdevice, a given wireless device may have varying degrees ofconnectivity. Typically, users are less concerned with the actual datachannel used to deliver or receive a message, and more concerned withthe content of the communication and to or from whom it was conveyed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example client-server environment.

FIG. 2 illustrates an example user device.

FIG. 3A illustrates an example network environment having multiplecommunication paths.

FIG. 3B depicts a simplified representation of the transport channelbetween messaging infrastructure servers and one or more client devices.FIG. 4A illustrates an example interface implementing a conversationsview.

FIG. 4B illustrates an example interface for viewing a particularconversation.

FIG. 5A illustrates an example method executed on a client device priorto transmitting a message.

FIG. 5B illustrates an example method executed server-side for theassignment of messages to conversation threads.

FIG. 6 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device to a messaging client recipient'sweb mailbox.

FIG. 7 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device to a messaging client recipient'sweb mailbox and client device via SMS.

FIG. 8A illustrates an example call flow for transmitting an outgoingmessage from a messaging client device to a messaging client recipient'sweb mailbox or client device based on one or more policies.

FIG. 8B illustrates an example call flow for transmitting an outgoingmessage to a recipient's client device via a special bind between themessaging SMS server and carrier SMSC.

FIG. 9 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device to an email recipient.

FIG. 10 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device to a phone number via SMS.

FIG. 11 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device to a phone number via an SMSshortcode.

FIG. 12 illustrates an example call flow for transmitting an outgoingmessage to multiple recipients or via multiple communication channels.

FIG. 13 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device when no data connection isavailable.

FIG. 14 illustrates an example call flow for transmitting an outgoingmessage from the web interface of a messaging service to a phone number.

FIG. 15 illustrates an example call flow for receiving an incomingmessage from a phone number.

FIG. 16 illustrates an example call flow diagram for retrievingvoicemails from a client's voicemail box.

FIG. 17 illustrates an example network environment.

FIG. 18 illustrates an example computing system.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENT(S)

Overview

This disclosure generally relates to transmitting data of disparatecommunication protocols or data channels between two or more clientdevices via an intermediate messaging service that aggregates all thecommunications into a single communications thread, regardless of typeor transport channel.

In particular embodiments, the messaging service applies or morepolicies to messages transmitted from or to client devices dictating themode of transmission for a particular device. In particular embodiments,where policies dictate transmitting a message via SMS, a MS server ofthe messaging service transmits the SMS to the carrier recipient via aspecial bind, allowing the message to appear as if it initiated from thetransmitting device rather than the SMS server. In particularembodiments, the transmitting client device transmits the message viaSMS after explicit instruction from the messaging service.

In particular embodiments, the messaging service connects directly toclient device's voicemail boxes and download voicemails to the messagingservice backend servers. In particular embodiments, client devicesdownload the voicemails from their carrier voice mailbox and transmitthem up to the messaging service backend server for aggregation.

In particular embodiments, the messaging service provides a common shortcode (CSC) that is in direct connection with the messaging servers. Aclient device lacking a data connection may transmit a message as an SMSto the CSC, after which the messaging service may deliver the message inaccordance with one or more recipient policies.

These and other features, aspects, and advantages of the disclosure aredescribed in more detail below in the detailed description and inconjunction with the following figures.

This disclosure is now described in detail with reference to a fewembodiments thereof as illustrated in the accompanying drawings. In thefollowing description, numerous specific details are set forth in orderto provide a thorough understanding of this disclosure. However, thisdisclosure may be practiced without some or all of these specificdetails. In other instances, well known process steps and/or structureshave not been described in detail in order not to unnecessarily obscurethis disclosure. In addition, while the disclosure is described inconjunction with the particular embodiments, it should be understoodthat this description is not intended to limit the disclosure to thedescribed embodiments. To the contrary, the description is intended tocover alternatives, modifications, and equivalents as may be includedwithin the spirit and scope of the disclosure as defined by the appendedclaims.

Notification Channel

In network communications, one device may “push” a communication toanother device. In particular embodiments, with push technology, thesending device typically initiates the communication transaction and maytransmit the communication to the receiving device without obtaining apermission from the receiving device first. In other words, thecommunication is “pushed” to the receiving device whether or not thereceiving device actually wants to receive the communication.

Push technology may be used under various circumstances. For example, ina client-server environment, a server may push communications to aclient. The client may be any type of electronic device capable ofnetwork communications. In particular embodiments, the client may be amobile device (e.g., a mobile telephone, a smart phone, a tabletcomputer, etc.) capable of wireless communications, and the server maypush communications, sent over a mobile network or a wireless network,to the mobile client. Alternatively or in addition, in particularembodiments, the client may be a non-mobile computing device (e.g., adesktop computer) capable of connecting to a computer network through awired connection (e.g., an Ethernet connection). The server may pushcommunications to the non-mobile client over the computer network (e.g.,the Internet).

In particular embodiments, a social-networking system implemented, forexample, as a social-networking website, may push communications to theclient devices of its users. A social network, in general, is a socialstructure made up of entities, such as individuals or organizations,that are connected by one or more types of interdependency orrelationships, such as friendship, kinship, common interest, financialexchange, dislike, or relationships of beliefs, knowledge, or prestige.In more recent years, social networks have taken advantage of theInternet. There are social-networking systems existing on the Internetin the form of social-networking websites. Such social-networkingwebsites enable their members, who are commonly referred to as websiteusers, to perform various social activities. For example, thesocial-networking website operated by Facebook, Inc. at www.facebook.comenables its users to communicate with their friends via emails, instantmessages, or blog postings, organize social events, share photos,receive news of their friends or interesting events, play games, etc.

In order to maintain connectivity with its users, a social networkingsystem may maintain a constant open connection with each of the mobiledevices associated with a particular user account. This open dataconnection allows the social networking system to push notifications toclient devices, the client devices to request content from the socialnetworking system, and the client devices to transmit information backto the social networking system servers. For example, a client devicemay wish to constantly update the social networking system of itslocation. As another example, the client device may wish to perform somesort of action on the social network, and may request, through HTTP oranother suitable protocol, a web page for performing the specificaction. In other cases, the social networking system may wish to push anotification of a message from one social networking user to another. Inparticular embodiments, this open data connection utilizes a TCP/IPconnection. In particular embodiments, the open data connection utilizesa VPN tunnel, such as in MICROSOFT DIRECT PUSH. In particularembodiments, the open data connection utilizes the SMS channels for pushnotifications. This disclosure contemplates any suitable manner ofmaintaining an open connection for unidirectional or bidirectionalcommunication between a social networking system and a client device.

FIG. 1 illustrates an example client-server environment 100 in which acommunication may be received from or pushed to a client device. Inparticular embodiments, the client device may be a mobile deviceassociated with a user. There may be any number of servers 110, 120, 130of various types and any number of clients 140 of various types. Eachserver 110, 120, or 130 may include hardware, software, or embeddedlogic components or a combination of two or more such components forcarrying out the appropriate functionalities implemented or supported byserver 110, 120, or 130. In particular embodiments, servers 110, 120,and 130 may be arranged in tiers. For example, there may be one or moreweb servers 110 for hosting a social-networking website. Each web server110 may be connected with one or more channel servers 120. Each channelserver 120 may be connected with one or more edge servers 130. Webservers 110, channel servers 120, and edge servers 130 may each performsome of the functionalities or operations supported by thesocial-networking website. For example, web servers 110 may host anetwork application or a web-based application, such as asocial-networking application or website. Channel servers 120 maymonitor and manage the available communication channels (e.g., mediadownloading or uploading, instant messaging, posting, emailing,chatting, presence, etc.) for the users of the application hosted by webservers 110. Edge servers 130 may maintain network or communicationconnections with user devices (e.g., clients 140) for messaging andother accesses. In addition, edge servers 130 may function as proxiesfor web servers 110. Clients 140 may communicate with web servers 110through edge servers 130. In particular embodiments, servers 110, 120,and 130 and clients 140 may each have a unique identifier. For example,each server 110, 120, and 130 may be identified by its unique IPaddress, and each client 140 may be identified by its unique deviceidentifier.

By using multiple servers, the workload of the social-networking websitemay be shared and balanced among the multiple servers and thus, theperformance of the social-networking website may be improved. Forexample, the social-networking website may have hundreds of millions ofusers around the world, and at any given time, a great number of theseusers may be connected to the website through their respective userdevices. New users may continually join the website as well. These usersmay be shared and balanced among multiple channel servers 120 to beserviced. In particular embodiments, a hash algorithm may be applied tothe user identifier (e.g., the username or account number) of each userto determine to which channel server 120 a specific user is assigned. Inaddition or alternatively, channel servers 120 may be placed atdifferent physical locations around the world, and a user may beassigned to a channel server 120 that is relatively close (e.g., interms of physical distance) to the user's device. For example, a userlocated in Japan may be assigned to a channel server 120 located inJapan or China; while a user located in England may be assigned to achannel server 120 located in France.

In particular embodiments, each client 140 may be associated with a useras a user device. Each client 140 may be a mobile or non-mobile deviceand connected to a network wirelessly or through a wired connection. Inparticular embodiments, when a user connects with the social-networkingwebsite through his/her client 140 (i.e., the user device), client 140may establish one or more connections with an edge server 130. Eachconnection may be a TCP/IP connection. More specifically, client 140 maybe connected with an edge server 130 that is connected to the channelserver 120 to which the user of client 140 is assigned.

Mobile Device

FIG. 2 illustrates an example client device 140. In particularembodiments, a client 140 may include hardware, firmware, and software.In particular embodiments, client device 140 may be a smart phone (e.g.,iPhone, Android-based phone, or Blackberry), which is a mobile telephonethat offers more advanced computing ability and connectivity than atraditional mobile phone. It may be considered as a handheld computerintegrated with a mobile phone. In particular embodiments, client device140 may be a netbook or tablet computer (e.g., iPad, Android-basedtablets). Client device 140 may be connected to a network through awireless connection, such as a GSM or CDMA2000-based wireless cellularnetwork.

In particular embodiments, client device 140 may include hardware 210and software 220. In particular embodiments, hardware 210 may includeany number of hardware components such as, for example and withoutlimitation, processor 211, memory 212, storage 213, transceiver 214,input/output device 215 (e.g., display, touch screen, keypad,microphone, speaker, etc.), camera 216, global positioning system (GPS)sensor 217, sensors hub 218, notification control switch 219, RFIDreader 241, RF sensor 242, and so on. This disclosure contemplates anysuitable hardware components. In particular embodiments, some or all ofa user's user data may be stored in storage 213.

In particular embodiments, software 220 may include an operating system221, which may include a kernel 231 and/or any number of device drivers232 corresponding to some of the hardware components available on clientdevice 140. Operating system 221 may be selected for client device 140based on the actual type of device client device 140 is. For example, ifclient device 140 is a mobile device (e.g., a smart phone), thenoperating system 221 may be a mobile operating system such as, forexample and without limitation, MICROSOFT's WINDOWS MOBILE, GOOGLE'sANDROID, NOKIA's SYMBIAN, APPLE's IOS, and SAMSUNG's BADA.

In particular embodiments, there may be a connection pool manager 222residing and executing on client device 140, which may be implemented ascomputer software. In particular embodiments, one or more softwareapplications 223 may be executed on client device 140. In particularembodiments, they may be native applications installed and residing onclient device 140. For example, one application (e.g., GOOGLE MAPS) mayenable a device user to view a map, search for addresses and businesses,and get directions; a second application may enable the device user toread, send, and receive emails; a third application (e.g., a webbrowser) may enable the device user to browse and search the Internet; afourth application may enable the device user to take photos or recordvideos using camera 216; a fifth application may allow the device userto receive and initiate VoIP and/or cellular network calls, and so on.In particular embodiments, there may be a software application (e.g.,notification control 241) that enables the device user to manage thenotifications pushed to client device 140. Each software application 220may have a user interface and may implement one or more specificfunctionalities. Each software application 220 may include one or moresoftware modules implementing the individual functionalities. Theexecutable code of software applications 220, including notificationcontrol 241, may be stored in a computer-readable and non-transitorymedium (e.g., storage 213 or memory 212) on client device 140.

Network Environment

FIG. 3A illustrates an example network environment 300 having multiplecommunication paths. Network environment 300 includes one or more clientdevices 140, 140A, 140B, and 140C, wireless cellular networks 300 and300A, and messaging infrastructure 307 for providing a unified messagingservice to its users.

Client devices 140 and 140A, connect via wireless transmission media toa plurality of RF transceiver stations 305 and 305A operated by wirelesscellular networks 300 and 300A. In particular embodiments, mobiledevices 140 and 140A may obtain connectivity to Internet 306 through oneor more wired or wireless networks not operated by wireless cellularnetwork 300 and 300A operators. For example, mobile devices 140 and 140Amay connect to Internet 306 through public or private 802.11 WiFinetworks, 802.3 wired Ethernet LANs, 802.16 WIMAX wireless networks, orBLUETOOTH personal area networks (not shown). For the purposes of thisdisclosure, mobile devices 140 and 140A do not distinguish between dataconnections through the aforementioned non-cellular data networks andwireless cellular networks 300 and 300A; so long as they have dataconnectivity, the data delivery channel is considered active andavailable.

In particular embodiments, mobile devices 140 and 140A may each beassociated with a unique user identifier for a messaging service orsocial networking system. In particular embodiments, mobile devices 140and 140A may associate with a particular user identifier the first timea user of mobile devices 140 and 140A log into the messaging service orsocial networking system. In particular embodiments, users with accessto accounts on the messaging service or social networking systemassociated with the user identifiers may access the service/systemthrough web clients 150 and 150A from any terminal having access toInternet 306. In particular embodiments, web clients 150 and 150A arenot associated with any particular user identifier until the userprovides login credentials; any number users of the messaging service orsocial networking system may access their respective accounts through asingle web client 150 or 150A. In particular embodiments, In particularembodiments, mobile devices 140 and 140A may be installed with amessaging client application that overrides gen

In particular embodiments, mobile devices 140 and 140A connect to amessaging service or social networking system via the notificationchannel as described above. In particular embodiments, a dedicatedmobile application maintains the “always-on” data connection betweensocial networking servers 307 or messaging infrastructure. In particularembodiments, the mobile application replaces conventional mobile devicephone applications controlling dialing, email, SMS text messaging,picture messaging, instant messaging, voicemail, etc. into a unifiedmessaging client. For the purposes of this disclosure, mobile deviceshaving an associated user identifier with the social networking systemor messaging service, as well as a unified messaging applicationreplacing traditional mobile device messaging applications andmaintaining an always-on notification/data channel to the socialnetworking system or messaging service, such as mobile devices 140 and140A, are herein referred to as “messaging client devices.”

Mobile devices 140B and 140C represent mobile devices connected towireless cellular networks 300 and 300A that either lack the messagingclient described above; in other words, “plain” mobile devices, ordevices having the messaging client but who have no data connectivity.Thus in certain scenarios, users of messaging client devices may send toor receive from mobile devices unassociated with any particular useridentifiers on the social networking system or messaging service. Inother scenarios, messaging client devices may only have connectivitythrough SMS and voice channels, as described in further detail below,and cannot connect through a data channel to the social networkingsystem or messaging service.

As one of ordinary skill in the art may recognize, wireless cellularnetworks 300 and 300A may be provided by the same or different wirelesscarriers. Wireless cellular networks 300 and 300A may be of any suitabletype, including without limitation, GSM-based cellular networks(including but not limited to EDGE, GPRS, UMTS, HSDPA/HSUPA, LTE, andthe like) or CMDA-based cellular networks (including but not limitedCDMA2000, EVDO, LTE, and the like). Wireless cellular networks 300 and300A connect to the public IP network/Internet 306 through theirpacket-switched core networks 301 and 301A, and to the public-switchedtelephone network (PSTN) or IP-based voice branch exchanges throughcircuit-switched networks 303 and 303A. Each wireless cellular network300 and 300A's carrier maintains one or more short message servicecenters (SMSCs) 302 and 303A for receiving, storing, and delivering SMStext messages and MMS messages. When transmitting an SMS message fromone carrier network to another, such as from SMSC 302 to SMSC 302A,messages are commonly routed through inter-exchange carrier (IXC 304).

In particular embodiments, each subscriber to wireless cellular networks300 and 300A may have an associate voice mailbox on carrier voicemailservers 312 and 312A. Typically, subscribers dial to a particularnumber, at which point they must authenticate with voicemail servers 312and 312A to obtain access to their stored voicemails. In particularembodiments, voicemail servers 312 and 312A may authenticate via callerID and a password. In particular embodiments, the user must enter bothhis or her cellular number and password. In particular embodiments,voicemail servers 312 and 312A may automatically authenticate using thesubscriber's device media access control (MAC) address. In particularembodiments, voicemail servers 312 and 312A utilize push communicationsto transmit stored messages as audio files to subscriber devices. Inparticular embodiments, voicemail servers 312 and 312A utilize pushcommunications to deliver new message notifications. In particularembodiments, the push notifications may be through the SMS channel. Inparticular embodiments, voicemail servers 312 and 312A performspeech-to-text processing, and deliver a transcription of storedvoicemails in the form of emails, SMS text messages, or other textformats. This disclosure contemplates any suitable voicemail servers 312and 312A.

Mobile devices 140, 140A, and users of web clients 150 and 150A connectto social networking system servers 307 through Internet 306. For thepurposes of this disclosure, the unified messaging system is implementedby, and integrated with, a social networking system. However, one ofordinary skill in the art can envision a unified messaging system thatis untied from a social networking system. In particular embodiments,the unified messaging system may integrate with other third-party sites,such as crowd-sourced review sites, shopping sites, and the like. Inparticular embodiments, the unified messaging system may integrate witha plurality of social networking system, email services, voice-over-IP(VoIP), video chat, push to talk (PTT), or other communication services.This disclosure contemplates a unified messaging system that mayintegrate with any suitable communications service or protocol. For thepurposes of this disclosure, the term “messaging infrastructure” and“social networking system” are interchangeable.

Messaging infrastructure 307 may include one or more messaging servers308-311 collectively providing a unified messaging infrastructure.Mailbox server 308 facilitates delivery, organization, and storage ofmessages relayed through social networking servers 307. Mailbox server308 maintains a user mailbox 160, 160A, etc. for each user of the socialnetworking system. In particular embodiments, users may view theirmailbox from messaging client applications on mobile devices 140 and140A, or by logging in to a social networking website via web clients150 or 150A.

Mailbox server 308 is also responsible for organizing all messages intoindividual conversation threads. For example, if user A and user Bcommunicate over the course of their relationship via a plurality ofcommunication methods, such as email, phone, text, etc., mailbox serveraggregates all the messages exchanged between user A and user B into asingle thread. Thus both users A and B may quickly access all theirinteractions with each other from their mobile device or through a webinterface without concerning themselves as to what service was used todeliver or send the message. Similarly, users do not need to concernthemselves with deciding how to best reach a particular user. Thesefeatures are described in further detail below.

Mailbox server 308 may, in particular embodiments, store conversationthreads in a thread database 308A. Thread database 308A may be aseparate server from, or in particular embodiments, a part of mailboxserver 308. In particular embodiments, thread database 308A may comprisemultiple distributed servers to cope with the requirements of storing alarge number of messages for potentially hundreds of millions of users.In particular embodiments, conversation threads are organized by theparticipants in the conversation. In the example above, a conversationbetween users A and B would constitute a unique thread having a uniquethread identifier (thread ID). As another example, a conversationbetween users A, B, and C could, in particular embodiments, constituteanother unique thread (and similarly having its own unique thread ID).In particular embodiments, the conversation participants are identifiedby their unique social networking user identifier. In particularembodiments, the conversation participants are identified by their phonenumber. Particular exemplary methods of sorting messages and associatingthem with conversation threads is discussed further with reference toFIG. 5A.

Mailbox server 308 may, in particular embodiments, access a policydatabase 308B containing a set of policies for each user defining howeach user wishes to send or receive messages. For example, certain usersmay wish to only receive messages via email to avoid messaging charges.As another example, certain users may wish to reduce data plan chargesand transmit messages only via SMS. In particular embodiments, users mayfine tune their message delivery policies based on any definable factor.For example, a user may enter his or her messaging plan details, forexample, that he or she receives 300 free SMS text messages per billingcycle, and specify that all messages after 300 are to be transmitted orreceived via SMS. As one of ordinary skill in the art can envision,these policies may be applicable to any conceivable communicationsservice or protocol; for example, a user may specify that all calls bedelivered over a VoIP client when data service is available, and onlythrough circuit-switched network 303 when a data connection isunavailable. In particular embodiments, the social networking system mayimplement selectable policy modes, such as “best effort” (delivering themessage through any available communications channel), “guaranteeddelivery” (delivering the message only through SMS or data protocolsthat acknowledge reception or reading, such as BBM or Kik messenger),“low bandwidth” (delivering the message as cheaply as possible), and thelike. In particular embodiments, the policy may be based off theexplicit or inferred urgency of a message. For further discussion of anurgency indicator for messages, please see commonly owned U.S. patentapplication Ser. Nos. 13/277,096 and 13/277,121, respectively entitled“Urgency Notification Delivery Channel” and “Inferential UrgencyNotification Delivery Channel”, both filed on 19 Oct. 2011, and hereinincorporated by reference. This disclosure contemplates any suitablemethod of defining message transmission/reception policies based on anynumber of factors.

In particular embodiments, messaging infrastructure 307 includes asimple-mail transfer protocol (SMTP) server 310. SMTP server transmitsemail to external email accounts. In particular embodiments, SMTP server310 may transmit all emails from a default email address on behalf of aparticular user, such as username@facebook.com. In particularembodiments, SMTP server 310 may perform email sender spoofing togenerate an email message that appears to have originated from adifferent email account; for example, an employee may wish for allmessages to appear to have gone through his employer's domain. Inparticular embodiments, the user may configure one or more policies inpolicy db 308B that dictates what address SMTP server 310 spoofs.Methods of email address spoofing are well known in the art and will notbe discussed further here.

In particular embodiments, messaging infrastructure 307 includes acommon short-code (CSC) server 311. CSC server 311 receives SMS messagesfrom messaging client devices addressed to a special short code, such as“32665.” In particular embodiments, CSC Server 311 also transmits SMSmessages to messaging client devices 140, 140A, as well as non-messagingclient devices 140B, and 140C. Short codes (also known as short numbers)are special telephone numbers, significantly shorter than full telephonenumbers, that can be used to address SMS and MMS messages from certainservice provider's mobile phones or fixed phones. Short codes aredesigned to be easier to read and remember than normal telephonenumbers.

In particular embodiments, messaging infrastructure 307 includes an SMSserver 309 for transmitting SMS messages directly to carrier SMSCs. Inparticular embodiments, the social networking system may establishspecial relationships with carriers of wireless networks 300 and 300A toconfigure “special binds” between SMS server 309 and carrier SMSCs 302and 302A. These special binds permit the messaging infrastructure totransmit an SMS message to a non-messaging client mobile device whilespoofing the phone number of the sender. For example, if messagingclient user A transmits an SMS message to a mobile phone number onwireless cellular network 300A using the CSC server, user B receives anSMS from, for example, “32665” instead of the mobile number of user A.(This concern is not an issue when user B utilizes the unified messagingclient, which will replace the sender number with the appropriate username.) However, when transmitting a message using a special carrierbind, the recipient mobile phone receives an SMS with the phone numberof User A's device in the “from” field, even though the SMS actuallyoriginated from SMS server 309. In particular embodiments, SMS server309 connects to carrier SMSCs via a short message peer-to-peer (SMPP)message over Internet 306. In particular embodiments, SMS server 309 maybe part of CSC server 311. In particular embodiments, SMS server 309 andCSC server 311 may share a common IXC 304. This disclosure contemplatesany suitable arrangement of servers for the delivery of SMS messages tocarrier SMSCs 302 and 302A.

Social networking system/messaging infrastructure 307 may include webservers 110, channel servers 120, and edge servers 130, as previouslydescribed with reference to FIG. 1. Client devices 140 and 140A may beconnected to the same or different ones of web, channel, and edgeservers 110, 120, and 130, respectively.

As previously discussed, messaging infrastructure 307 maintains anotification channel (depicted as the solid line in FIG. 3A) with bothmobile device 140 and 140A. As previously discussed, the notificationchannel may be a persistent TCP/IP connection, VPN tunnel, or any othersuitable persistent data connection. The notifications channel betweenservers 307 and mobile devices 140 maintains a connection throughInternet 306 and the packet-switched (data) core network 301 of mobiledevice 140's wireless cellular network 300. From wireless cellularnetwork 300, the data is transmitted to RF transceiver 304 (the celltower, base station, Node B, and the like) that is servicing mobiledevice 140. Similarly the notification channel between social networkingservers 306 and mobile device 140A maintains a connection throughInternet 305 and packet-switched (data) core network 301A in mobiledevice 140A's wireless cellular network 300A. Wireless cellular networks300 and 300A may be disparate wireless cellular networks, or wheremobile devices 140 and 140A are serviced by the same carrier, a singlewireless cellular network.

As previously discussed, the notification channel may be a persistentTCP/IP connection, and mobile devices 140 and 140A may periodically sendkeepalive messages to social networking system/messaging infrastructure307. In particular embodiments, mobile devices 140 and 140A adjust thekeepalive interval based upon an adaptive algorithm. In particularembodiments, keepalive messages are transmitted at a pre-set interval.In particular embodiments, keepalive messages may be transmitted fromthe server to the handsets. In particular embodiments, the notificationchannel utilizes the packet-switched data network for upstream data,such as HTTP requests or uploads from mobile devices 140 and 140A, andSMS channels 302 and 302A for pushing notifications to mobile devices140 and 140A. This disclosure contemplates any suitable method ofestablishing and maintaining a persistent data connection between socialnetworking system 307 and mobile devices 140 and 140A.

FIG. 3B is a simplified representation of the transport channel 312between messaging infrastructure servers 307 and one or more clientdevices 140. The users of messaging client mobile devices 140 and 140Aare agnostic and unaware of the means by which their messages andcommunications are relayed to other users via messaging infrastructure307. Thus, at a high level of abstraction, messaging client mobiledevices 140 and 140A maintain a connection to messaging infrastructure307 via transport pipe 312, where the transport pipe may be any numberof different protocols or data networks. For example, in FIG. 3B,transport pipe 312 comprises notification channel 312A and SMS channel312B. As previously stated, notification channel 312A may be through anypacket data network, whether cellular or WiFi/WIMAX. Similarly, SMSchannel 312 b may utilize SMS short code server 311 or SMS server 309,or any combination of the two. Thus, messaging server 307 determines,based on connectivity and policies stored in policy db 308B, which ofthe paths 312A or 312B within transport pipe 312 should be used totransmit or receive a given message for a mobile device 140 or 140A.(Clearly, for non-messaging client devices 140B-C, the only transportpath available is SMS channel 312B).

Because of the size constraints of SMS, in particular embodiments, whentransmitting messages via SMS channel 312B, both messaging client mobiledevices 140, 140A as well as messaging infrastructure 307 performs SMSconcatenation. In particular embodiments, concatenated SMS messages aretransmitted in accordance with 3GPP TS 23.040. In particularembodiments, concatenated SMS messages are transmitted with a user dataheader (UDH) that includes the number of total messages in the sequenceand the particular message's number in the sequence. Methods oftransmitting messages longer than 160 characters as multipleconcatenated SMS messages are well-known in the art, and will not bediscussed in detail here.

Conversation Thread User Interface

FIG. 4A illustrates an example interface implementing a conversationsview on a messaging client mobile device 140 or 140A in accordance withan embodiment. For didactic purposes, FIG. 2 illustrates the interfaceof a dedicated application, such as on a touchscreen-operated mobilephone. In particular embodiments, the interface includes an option forselecting the conversations view 401, an option for browsing a list ofcontacts 402, and option to browse contacts marked as favorites 403, andan option to launch the keypad 404. In particular embodiments, theinterface also includes a search bar 405, which allows the user tosearch both contact names and the content of conversations.

Upon selecting the conversations button 401, the application opens alist of conversations 420-435, arranged in this example, temporally withthe most recently active conversation first. The conversations areseparated into two tabs, “friends” 455 and “others” 460. Friends tab 455displays conversations with contacts that are also members of socialnetworking system. Others tab 460 displays conversations withparticipants who are not members of social networking system. Forexample, the may have a contact stored as “Mom” in their client device140 that does not correspond to a user on the social network. Theconversation between the user and his or her mom will be displayed in“others” tab 460. As another example, the user may receive a call from atelemarketer dialing from 650-555-5555, who is neither a member of thesocial network nor a stored contact. However, because call log data isgenerated for this incoming call, the conversation between the and650-555-5555 will be displayed in “others” tab 460.

The first conversation 420 represents a conversation between six users(all members of the social network)—Joel Seligstein, Dan Hield, Joe Lei,and 2 others. Conversations 425, 430, and 435 represent conversationswith individual contacts, in these examples, Grace O'Malley, Alex Chang,and James White.

For each conversation, a brief summary of the conversation is presentedin the interface. In one embodiment, the summary includes the names 440of the conversation participants, pictures 445 of the conversationparticipants, and an excerpt 450 from the most recent message in theconversation. In one embodiment, conversations including multipleparticipants do not have pictures 445 to save space. The summaries areorganized by time/date so that conversations with the most recentmessages are placed higher in the interface. The name and/or picture ofthe user that the mailbox belongs to (the “mailbox owner”) is notdisplayed in the summary because it is understood that the mailbox onlyincludes conversations in which the mailbox owner is a participant.

When a conversation has a large number of participants, in oneembodiment only a sub-set of the names are presented to simplify thesummary. The sub-set can be any number of participants from theconversation. For example, conversation 420 has six participants. In oneembodiment, only the names of a sub-set of conversation participants aredisplayed. The name of the mailbox owner is not shown in the summary.The names of the other participants are grouped together and presentedas “2 others.”

In one embodiment, the brief excerpt 450 may be extracted from thecontent of the most recent message in the conversation. For example, inconversation 420, the excerpt 440 includes the text “But do you alwayshave to match your shoes . . . ” which is the most recent message fromthis conversation 420. In other embodiments, the brief excerpt isextracted from other information that is not message content, such asmetadata associated with the message. For example, the brief excerptcould be the title of the most recent e-mail message in theconversation.

In one embodiment, the mailbox server 308 aggregates messages ofdifferent formats (e-mail, SMS text, instant message) and communicationprotocols (voice, VoIP, video, etc.) into conversations. Eachconversation thus becomes a historical record of all correspondencebetween a set of users regardless of the format of the messages or logdata. For example, if Adam sends an online instant message to Bob andalso separately sends an e-mail to Bob, both of these messages areplaced into the same conversation. Similarly, if Bob leaves Adam avoicemail, an indicator of the voicemail (such as the date and time itwas left), or, alternatively, transcribed text from the voicemail, willbe placed into the conversation. As another example, if Adam calls Bob,the log of the call will be placed in the conversation as well. Thus theconversations window groups all communications, irrespective of formator protocol, in a single history for each of the user's real-worldcontacts.

FIG. 4B illustrates a conversation that aggregates different messageformats according to an embodiment. The user can reach this display byselecting one of the conversations in the interface of FIG. 4. Inparticular embodiments, the interface includes buttons to message 480,and call 485 the contact.

Shown is a one on one conversation between the user and James White thatcomprises of a series of messages 470. Although messages may have beendelivered via different accounts and with different communicationsservices, such as email, IM, text, etc., each message is merelydisplayed as a message without further indication of how the message wasdelivered. Icon 465 indicates a message was marked by James as “urgent.”Icon 475 indicates that there was an incoming phone call from JamesWhite, and the entry associated with icon 475 indicates that the callwas received yesterday at 11:00 AM and lasted 4 minutes, 53 seconds. Theconversation can be updated live as new messages are received thatupdate the conversation. As discussed above, a conversation is akin to ahistorical record of all correspondence between a set of users. Throughthe interface, a mailbox owner can scroll backwards in time to view theentire history of the messages in the conversation. In one embodiment,some of the messages can have attachments such as pictures, videos,documents, etc. The pictures and video can be shown in the interfacewith a preview of the attachment instead of just a link to theattachment. For example, an attached picture can be shown in theinterface with a thumbnail of the picture. For the mailbox owner, theconversation appears to include both outgoing and incoming messages andlog data.

Conversation Thread Creation

FIG. 5A illustrates an example method executed on a client device priorto transmitting a message. While mailbox server 308 is responsible forthe organization and storage of messages in threads, messaging clientapplication residing on mobile devices 140 and 140A may store a localcopy of all or a portion of its associated conversation threads storedin mailboxes 160 and 160A, respectively. In particular embodiments,messaging client only stores messages from a predetermined duration,such as the last month. In particular embodiments, messaging clientdevice only stores messages until a given amount of storage is consumedfor the thread. In particular embodiments, messaging client devicebegins downloading more messages when a thread is opened, such as inFIG. 4A. This disclosure contemplates any suitable method of locallystoring conversation threads.

At Step 501, the user of mobile device 140 initiates a message to arecipient. The user may initiate this communication in a variety ofways. For example, referring to FIG. 4, the user may select an existingthread 420-435 from his or her threads with friends, and, upon beingtaken to the thread view of FIG. 4B, select the “message” button 480 orthe “call” button 485). The user may perform this same process forthreads in the “others” tab 460. The user may also select the “newmessage” option and enter a phone number or select a contact from his orher locally or remotely stored list of contacts. The user may alsoactuate keypad 404 and enter a phone number to initiate a voicecommunication. Regardless of the method the user initiates acommunication at Step 501, the client device proceeds to step 502.

At Step 502, the client device checks whether the communication belongsin an existing thread. For example, if a user selects a thread andreplies to a message in the thread, mobile device 140 is aware that themessage belongs in the existing thread. As another example, if the usermanually selects one or more contacts or enters one or more recipientnumbers, client device 140 may perform a lookup of locally storedthreads for the same recipients. As an example, referring to FIG. 4A, ifthe user selects “new message” and enters the number for Alex Chang,mobile device 140 may search for locally stored conversation threadshaving only the user and Alex Chang as participants. In particularembodiments, as wireless data speeds increase and latency decreases,client device 140 may search existing threads by querying mailbox server308. This disclosure contemplates any suitable method of determiningwhether an outgoing communication belongs in a thread.

At Step 503, if client device 140 finds a thread matching theparticipants of the outgoing communication, client device 140 pulls thethread ID from the thread and appends it to the communication, whetherthe communication is a message or a call log entry. If client device isunable to find a thread having the same participants as the outgoingcommunication, at Step 504 client device 140 generates a unique offlineidentifier, or offline ID, for the message.

In particular embodiments, the offline ID is an identifier that isunique to each message. In particular embodiments, client device 140generates a UUID for each message it transmits or receives regardless ofwhether it is part of an existing thread. In particular embodiments,client device 140 only generates a UUID for messages that are not partof an existing thread. Given that there are potentially hundreds ofmillions of users each transmitting thousands of messages, an offline IDof sufficient size must be generated to maintain uniqueness. Inparticular embodiments, the offline ID is 128 bits long. In particularembodiments, the offline ID is generated by a random number algorithm.In particular embodiments, the offline ID is generated based on theclient device ID, time, GPS location, or other factors. Methods forgenerating universally unique identifiers (UUIDs) are well-known in theart, and are not further described herein. This disclosure contemplatesany suitable method of generating a unique offline ID for a message.

At Step 505, client device 140 builds a message object to transmit tomessaging infrastructure 307. In particular embodiments, the messageobject is a JavaScript Object Notation object. In particularembodiments, the message object includes the message body (or call logdata, if the communication is a call), the identifiers for therecipients (if the message is a new thread), the thread ID (if themessage is part of an existing thread), and the offline ID of themessage (if it exists).

Therefore, in particular embodiments, message objects for messagesbelonging to existing threads contain only the body and thread ID inorder to reduce message object size and therefore device bandwidth. Inparticular embodiments, messages that do not belong to an existinglocally-stored thread are transmitted in a message object containing themessage body, identifiers for the recipients, and the message offlineID.

At Step 506, client device 140 transmits the message to the recipient(for didactic purposes, mobile devices 140A and 140B of FIG. 3A), or tomessaging infrastructure 307 based on policies in policy DB 308B. Theindividual call flows for the various transmission scenarios aredescribed in further detail with reference to FIGS. 6-16.

Messaging infrastructure 307 periodically synchronizes mailbox 160 withlocally stored threads on mobile device 140. In particular embodiments,the synchronization occurs every time a transmission is sent by orreceived from mobile device 140. In particular embodiments, mobiledevice 140 synchronizes with messaging server 160 at predeterminedintervals, such as every thirty minutes. In particular embodiments,mobile device 140 synchronizes every time the user accesses the socialnetworking system. This disclosure contemplates any suitable method orinterval for synchronizing conversations threads stored locally onmobile device 140 and conversation threads stored remotely in mailbox160.

Techniques for synchronizing mailboxes are well-known in the art. Inparticular embodiments, mailbox server 307 compares all conversationthreads in user mailbox 160 with the locally-stored conversation threadson messaging client device 140, and subsequently pushes down newmessages or pulls up new messages and places them into threads. Inparticular embodiments, messages residing on client device that merelyhave an offline ID, that is, not belonging to an existing thread, arepulled from mobile device 140 to mailbox server 308, where the mailboxserver creates a new thread for the message, as further described below.This disclosure contemplates any suitable method of synchronizingmailbox 160 and a locally-stored copy of conversation threads on mobiledevice 140.

The process of FIG. 5B is also performed by a messaging client device(for example, device 140A in FIG. 3A), when receiving a message directlyvia an SMS channel. For example, a non-messaging client device such asdevice 140C may transmit an SMS directly from its carrier SMSC 302, viathe IXC 304, to the recipient's carrier SMSC 302A, to device 140A. Insuch a case, recipient mobile device 140A must generate an offline IDfor the message (as it will not have a thread ID) and transmit themessage to the server for synchronization and subsequent storage inmailbox 160A.

FIG. 5B illustrates an example method executed server-side for theassignment of messages to conversation threads. To begin the process,mailbox server 308 receives a message from a client device. Mailboxserver 308 may receive messages from messaging client devices 140 and140A through the data channel 312A, or, if no data connection isavailable, through the SMS channel 312B, either via SMS server 309 orSMS short code 311. Mailbox server 308 may receive devices directly fromweb clients 150 and 150A, and from non-messaging client devices 140B and140C through short code (CSC) server 311. In particular embodiments,where a special bind exists between the transmitting device's carrier302 and SMS server 309, a non-messaging client recipient (for exampledevice 140B) may reply to an SMS from SMS server 309 wherein the “from”field of the message is spoofed to match the phone number of thetransmitting device. In such embodiments, the reply message may bedelivered directly to the transmitting handset. In particularembodiments, the reply message may be delivered to SMS server 309, andsubsequently, mailbox server 308.

Upon reception of a message to be transmitted to a messaging clientdevice (for example device 140A in FIG. 3A) or on behalf of a messagingclient device (for example, device 140) at Step 507, mailbox server 308checks if the message includes a thread ID. If the message includes athread ID, at Step 508 mailbox server 308 simply appends the message tothe end of the thread, stored in thread database 308B, identified by thethread ID. If the message does not contain a thread ID, mailbox server308 at Step 509 performs a reverse-lookup in order to determine if themessage belongs in an existing thread. In particular embodiments,messaging infrastructure 307 performs a reverse-lookup by querying adatabase of user profiles with a phone number, and receiving a socialnetworking user identifier in response. In particular embodiments,messaging infrastructure 307 performs a reverse lookup by calling asocial networking application programming interface. This disclosurecontemplates any suitable method of performing a reverse lookup.

Different data may be transmitted in a message or message object lackinga thread ID depending on the transmitting client device. For example, amessaging client device 140 with a data connection may transmit explicitsocial networking user identifiers for the participants in a messagethread (the recipients of the message). However, in particularscenarios, a user may not have explicitly linked a phone number or phonecontact with a social networking user ID. For example, a particular usermay have a contact in his or her mobile device named “Mom” but notlinked to the individual's actual social networking account. In such ascenario, messaging client device 140 or 140A may transmit a messageobject merely containing the phone number (for didactic purposes, assumethe phone number for “Mom” is 555-213-6689 and is represented by a usernamed “Jane Smith” on the social networking system) for threadparticipant. In particular embodiments, users of the social networkingsystem may have published or unpublished phone numbers based on theirprivacy settings. For example Jane Smith may have listed the number555-213-6689 on her social networking profile. In such a scenario,mailbox server 308, upon receiving a message including a participantidentifier of “555-213-6689”, calls the social networking API to performa reverse lookup for users associated with the number “555-213-6689.” Inthis case, the social networking API may return the user identifier for“Jane Smith,” and the message may be stored in a thread containing thesender and “Jane Smith.”

In particular embodiments, whether the social networking API returnsuser IDs associated with a particular phone number after areverse-lookup operation depends on the privacy settings of therecipient. For example, a particular user may wish to separate his orher business phone number from his social networking account; avoiding asituation where a business contact is suddenly and unintentionally awareof his identity on the social networking system. Thus, the socialnetworking API may consult a privacy database in order to determinewhether a number is “published” or “private.” For the purposes of thisdisclosure, “published” means that the number is visible to the senderon the recipient's social networking profile. For example, Jane Smithmay have privacy settings that allow her immediate family to see thenumber 555-213-6689 on her profile. In such a scenario, if her sontransmits a message object having the number to mailbox server 308, thereverse lookup will return Jane Smith's social networking useridentifier, even though her son has not explicitly linked “Mom” to “JaneSmith” in his mobile device. Extending this example, a user of amessaging client device 140 may have exchanged messages or calls withJane Smith without knowing her identity, for example, in connection withgoods or services offered on sales sites such as www.craigslist.org.Upon synchronizing the user's messaging client device 140 with themailbox server, the user will only see the phone number without JaneSmith's associated user ID in order to protect privacy settings.

In particular embodiments, a first user may have explicitly linked aphone number to a second user on the first user's mobile device 140,even though the second user has not made the number public to the firstuser. In the above example, assume Jane Smith has not published thenumber 555-213-6689 on her user profile, but her son has made anexplicit connection on his mobile device between the number and JaneSmith on the social networking system. In such a scenario, mailboxserver 308 will only use Jane Smith's social networking user identifierfor communications with the user who made the explicit linkage, in thiscase, her son. For example, if the son transmits a group message to userB and Jane Smith, the son's mailbox will contain a conversation threadbetween himself and Jane Smith, but user B's mailbox will only reflect aconversation thread between user B and 555-213-6689.

After resolving performing a reverse lookup and resolving the one ormore participant's phone numbers with users of the social network atStep 509, mailbox server 308 searches for threads containing the sameset of participants in thread database 308B. If a matching thread isfound, at Step 510 the mailbox server appends the new message to thematching thread.

If no matching thread is found, at Step 511 mailbox server 308 creates anew thread ID for the message, and includes a copy of the message ineach of the participants' mailboxes. Then, based on the type of messageand the policies dictating delivery to individual recipients, mailboxserver 308 applies policy-based delivery to the message and, foroutgoing messages, transmits the message to the intended recipient. Foran incoming message, i.e., received by a messaging client device andtransmitted up to messaging infrastructure 307, mailbox server 308merely updates the recipient mailbox.

Message Delivery

The following call flow diagrams illustrate example methods ofdelivering a message via messaging infrastructure 307. As a generalprinciple, the unified messaging system routes all messages throughmessaging infrastructure 307, if possible, and if not, transmits a copyof the message for storage in users' mailboxes. As another generalprinciple, the unified messaging system transmits as little informationas possible through the user of thread IDs. Individual use cases aredescribed in detail below.

FIG. 6 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device 140 to a messaging client device140A as well as associated web mailboxes 160 and 160A. In particularembodiments, at Step 601, the messaging client application on mobiledevice 140 requests mailbox server 308 to transmit a message by making arepresentational state transfer (REST) API call over a transport layersecurity (TLS) connection. In particular embodiments, the connection isa secure socket layer (SSL) connection.

At Step 602, mailbox server 308 stores the message in the transmittinguser's mailbox 160, and at Step 603, mailbox server 308 stores themessage in the recipient's mailbox 160A. At Step 604, messaging server308 transmits the message over data channel 312A to the messaging clientresiding on mobile device 140A. The receiving user may view the incomingmessage via the messaging client on his or her mobile device 140A.

FIG. 7 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device 140 to a messaging clientrecipient's web mailbox 160A and client device 140 via SMS channel 312B.At Step 701, the messaging client application on mobile device 140requests mailbox server 308 to transmit a message by making REST APIcall over a TLS connection. At Step 702, mailbox server 308 stores themessage in the transmitting user's mailbox 160, and at Step 703, mailboxserver 308 delivers the message by storing the message in therecipient's mailbox 160A.

At Step 704, determines that it should utilize SMS channel 312B todeliver the message to recipient mobile device 140A if, for example,recipient mobile device 140A lacks a data connection and is thereforeoffline. Mailbox server 308 transmits the message to SMS server 309, or,alternatively, CSC server 311 instructing it to transmit the message tothe mobile device.

At Step 705, SMS server 09 or CSC server 311 routes the message over anSMPP bind to the recipient carrier SMSC 302A, who then delivers themessage as an SMS to recipient mobile device 140A. Where CSC server 311is utilized, the recipient receives the message as an SMS from thesocial networking system shortcode. Where a special bind exists betweenthe social networking SMS server and the carrier SMSC 302A, therecipient receives a spoofed SMS having the phone number of mobiledevice 140 in the “from” field.

FIG. 8A illustrates an example call flow for transmitting an outgoingmessage from a messaging client device 140A to a messaging clientrecipient's web mailbox 160A or client device 140A based on one or morepolicies. At Step 801, the messaging client on mobile device 140 queriesmailbox server 308 over data channel 312A to obtain a message routingpolicy by making a REST API call over a TLS connection. In response,mailbox server 308 looks up the routing policies for both thetransmitting device as well as the recipient device, and determineswhether the outgoing message should be sent over data channel 312A orSMS channel 312B.

If policy dictates that the message be transmitted over data channel312A, at Step 802 the messaging client on mobile device 140 transmitsthe message to mailbox server 308 and requests mailbox server 308 (via aREST API call over TLS, in particular embodiments) to transmit themessage. At Step 803, mailbox server 308 stores the message in thetransmitting user's mailbox 160, and at Step 804, mailbox server 308delivers the message by storing the message in the recipient's mailbox160A. At Step 805, mailbox server 308 delivers the message to themessaging client residing on mobile device 140A over data channel 312A.

If policy dictates that the message be transmitted over SMS channel312B, at Step 802′ the messaging client on mobile device 140 requestsits mobile carrier SMSC 302 to transmit the message. In particularembodiments, this request is transmitted over the SS7 protocol. At Step803′, recipient mobile device 140A receives an SMS message fromtransmitting mobile device 140's mobile phone number via its cellularcarrier. At Step 804′, the messaging client on mobile device 140requests mailbox server 308 to save the message. In particularembodiments, this request is a REST API call, and in Step 805 mailboxserver 308 stores the message in the transmitting user's mailbox 160. Inparticular embodiments, the new message received by mobile device 140Ais pulled and stored in the recipient user's mailbox 160A on mailboxserver 308 upon the next synchronization operation. In particularembodiments, the message is stored in mailbox 160A upon delivery at Step805′.

FIG. 8B illustrates an example call flow for transmitting an outgoingmessage to a recipient's client device 140A via a special bind betweenthe messaging SMS server 309 and carrier SMSC 302 or 302A. At Step 801a, the messaging client on mobile device 140 queries mailbox server 308over data channel 312A to obtain a message routing policy by making aREST API call over a TLS connection. If mailbox server 308 responds thatthe message should be delivered via SMS channel 312B, at Step 802 a,messaging client on mobile device 140 invokes SendAPI in order toinstruct mailbox server 308 to transmit the message to the recipient viaSMS message. At Step 803 a, mailbox server 308 stores the message in thetransmitting client's mailbox 160. At Step 804 a, mailbox server 308directly transmits a request to SMS server 309 to send the message tothe messaging client on mobile device 140A. SMS server 309, at Step 805a, transmits an SMS message to recipient mobile device 140A with the“from” field spoofed to reflect transmitting device 140A's mobilenumber. In particular embodiments, the special bind is with thetransmitting carrier SMSC 302, and in particular embodiments the specialbind is with the recipient SMSC 302A. In particular embodiments, SMSserver 309 has a special bind with an IXC 304 to facilitate senderaddress spoofing.

In particular embodiments, Steps 801 a and its response may be omitted,and mailbox server 308 may resolve the delivery policy for a particularuser. For example, mobile device 140 may simply invoke SendAPI andtransmit the message to mailbox server 308 over data channel 312A.Mailbox server 308 may then resolve the delivery policy for therecipient, and, independent of any further action from mobile device140, may route the message to mobile device 140A as depicted in steps803 a-804 a.

FIG. 9 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device 140A to an email recipient. AtStep 901, the messaging client on mobile device 140 queries mailboxserver 308 over data channel 312A to obtain a message routing policy bymaking a REST API call over a TLS connection. At Step 902, mailboxserver 308 stores the message into the mailbox 160 of the transmittinguser. At Step 903, mailbox server determines through stored policies forthe transmitting or recipient users that the message should be deliveredthrough email, and transmits the message to messaging SMTP server 310.In particular embodiments, mailbox server 308 requests SMTP server 310to utilize a default social networking email address for the recipient,for example, steve@facebook.com. In particular embodiments, therecipient email address is pulled from the recipient's social networkingprofile. In particular embodiments, the recipient user may configurepolicies that dictate message delivery to a particular email address oraddresses. In particular embodiments, the recipient user may configure apolicy that dictates message delivery to a particular email address onlyfor particular transmitting users. Step 904, SMTP server 310 transmitsthe message vial email over Internet 306 to the recipient's inbox. Inparticular embodiments where the recipient email account is hosted bythe social networking system, the message does not need to traverse thepublic IP network.

FIG. 10 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device 140 to a phone number via SMS.The phone number may, without limitation: that of a non-messaging clientdevice 140B, 140C, a land line that accepts SMS messages, a VoIP numberprovided by a service such as GOOGLE VOICE, any phone number not linkedon the transmitting device or the social networking system with a useridentifier, or another SMS short code. At Step 1001, the messagingclient on mobile device 140 requests its carrier SMSC 302 to send themessage via SMS.

At Step 1002, the transmitting user's carrier SMSC 302 recognizes thatthe number is for a different carrier, and forwards the SMS to IXC 304.At 1003, the recipient receives the message as an SMS from mobile device140's number, routed through IXC 304.

In order to keep the transmitting user's mailbox 160 synchronized, atStep 404, the messaging client on mobile device 140 transmits a copy ofthe message to mailbox 308 and requests it to save the message. Inparticular embodiments, this is via a REST API call over a TLSconnection. At Step 1005, mailbox server 308 stores the message in thetransmitting user's mailbox 160.

FIG. 11 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device 140 to a phone number via CSCserver 311. At Step 1101, the messaging client on mobile device 140requests its carrier SMSC 302 to send a message via SMS to a particularshort-code number, such as 32655. At Step 1102, carrier SMSC 302transmits the message to CSC server 311. As previously disclosed, CSC311 may be a separate server from SMS server 309, or merely anapplication running on SMS Server 309 or another server. At Step 1103,the messaging client on mobile device 140 requests the mailbox server308 save the message by making a REST API call over a TLS connection. AtStep 1104, mailbox server 308 stores the message in the transmittinguser's mailbox 160.

FIG. 12 illustrates an example call flow for transmitting an outgoingmessage to multiple recipients or via multiple communication channels.At Step 1201, the messaging client on mobile device 140 instructsmailbox server 308 over data channel 312A to transmit the message tomultiple users. At Step 1202, mailbox server 308 stores the message inthe transmitting user's mailbox 160. At Step 1203, mailbox server 308delivers the messages to the mailboxes of multiple messaging servicerecipients, who may view the message through their mobile device 140A orover a web client 150A at Step 1203.1.

At Step 1204, mailbox server transmits a message to SMTP server 310,which then delivers the message as an email at Step 1204.1. At Step1205, mailbox server routes the message to phone recipients such as 140Bthrough SMS server 309 or CSC server 11 as previously described. Inparticular embodiments, a user may configure preferences that dictatethat they receive messages through multiple communication channels. Thusa user may receive multiple notifications for the same message.Additionally, the application of the method of FIG. 12, as well aschannel-agnostic message threading, greatly simplifies group messages.For example, a group of users may maintain an ongoing conversationthread on mailbox 308, even though one or more of the participants areutilizing different clients and communication channels. For example, aparticipant at work may find utilizing his email client is the mostconvenient, while a user away from his desk may find using the messagingclient on his phone the most convenient. Additionally, a user who doesnot have data connectivity, but has SMS network connectivity, will notmiss messages and may still participate even though he is in a datadead-zone, such as in the woods.

FIG. 13 illustrates an example call flow for transmitting an outgoingmessage from a messaging client device 140A when no data connection isavailable. For example, a user may be in an area where his or her mobiledevice 140 only has voice/SMS connectivity but no access to the packetswitched network. In such a scenario, the messaging client resident onmobile device 140 defaults to using SMS to transmit messages. At Step1301, the messaging client encodes an outgoing message into an SMS, andrequests its carrier SMSC 302 to send the message to CSC server 311. Inparticular embodiments, this operation is completely transparent to theuser; the user does not need to know the number for the shortcode, oreven that the message is being transmitted over SMS channel 312B.

At Step 1303, CSC server 311 decodes the SMS and requests mailbox server308 to transmit the message. At Step 1304, mailbox server 308 stores themessage in the outgoing user's mailbox 160. At Step 1305, mailbox server308 validates the recipient and delivers the message to his or hermailbox. The SMS transmitted to CSC server 11 may include one or morespecially formatted identifiers that designate the participants of theconversation. For example, the message may include a thread ID, socialnetworking user IDs for each participant, or phone numbers. Based on theinformation transmitted in the SMS, mailbox server 308 may need toperform different steps in the validation process. For example, if theSMS contains a thread ID, validation only requires delivering themessage to the participants of the thread. As another example, if theSMS contains social networking user IDs, mailbox server 308 needs todeliver a copy of the SMS to each user's mailbox. Finally, if only phoneparticipant phone numbers are included, mailbox server 308 must performa reverse lookup in order to validate the participants.

At Step 1306, the recipient may access the message via his or hermessaging client on mobile device 140A, or via web interface 150A.

FIG. 14 illustrates an example call flow for transmitting an outgoingmessage from the web interface 150 of a messaging service to a phonenumber. At Step 1401, a user accesses his or her mailbox 160 through webinterface 150. As previously disclosed, mailbox 160 may be representedas a website or other markup language documents displayed by a browseron web client 150. At Step 1401, the user requests mailbox server 308 totransmit the message to one or more recipients.

At Step 1402, mailbox server 308 stores the message in the transmittinguser's mailbox 160, and at Step 1403, mailbox server 308 requests SMSserver 309 to send the message as an SMS. At Step 1404, SMS server 309,or alternatively CSC server 311, routes the message over an SMPP bindfor the recipient carrier 302A, or to an SMS aggregator. At Step 1405,the recipient device, for example, messaging clients 140A and 140Breceives the SMS. Where the SMS is transmitted from CSC server 311, theshortcode appears in the “from” field. Where the SMS is transmitted fromSMS server 309, the “from” field is spoofed to display the phone numberof the transmitting device 140A, as previously discussed.

FIG. 15 illustrates an example call flow for receiving an incomingmessage from a non-messaging client device's phone number, for example,mobile device 140B. At Step 1501, the user of mobile device 140Brequests its carrier SMSC 302 to transmit an SMS message to the phonenumber of a messaging client mobile device 140A. At Step 1502, themessage is delivered via the recipient SMSC 302A and in particularscenarios, IXC 304. At this point the users of mobile device 140A isnotified via his or her messaging client and can view the message onmobile device 140A. In particular embodiments, mobile device 140A thenperforms the method of FIG. 5 in order to determine whether the messagebelongs in an existing thread or needs a new thread. As previouslydescribed, mobile device 140A creates a message object for transmissionto mailbox server 308.

At Step 1503, the messaging client on mobile device 140A requestsmailbox server 308 to save the message in the user's mailbox 160A bymaking a REST API call over a TLS connection. The messaging client onmobile device 140A transmits the message object to mailbox server 308;in particular embodiments, the message object is a JSON objects. At Step1504, mailbox server stores the message in its corresponding thread, orcreates a new thread for the message, in mailbox 160A.

Voicemail Proxy

FIG. 16 illustrates an example call flow diagram for retrievingvoicemails from a client's voicemail box 312. In particular embodiments,messaging infrastructure 307 is fully integrated with users' carriervoicemail box servers 312 and 312A, and messaging client mobile devices140, 140A are not involved in the retrieval of new voicemail messages,as seen in steps 1600-1604. In particular embodiments, messaging clientmobile devices 140, 140A retrieve new voicemails in a traditional pullfashion, but then transmits the message to messaging infrastructure 307,as seen in Steps 1601′ to 1604′.

The method of 1600-1604 requires, in particular embodiments, storage ofauthentication credentials for voice mailbox 312 in messaginginfrastructure 307. For example, when a user initially configures his orher messaging client, the client application may prompt the user toenter his authentication credentials for his or her voice mailbox. Inparticular embodiments, the authentication credentials comprise a pinnumber. In particular embodiments, the authentication credentialscomprise an email address and password. This disclosure contemplates anysuitable method of authenticating a user for accessing a voice mailbox.Upon receiving the authentication credentials, mailbox server 308, oranother server within messaging infrastructure 307, stores theauthentication credentials in association with the social networkinguser account for the mobile device.

At Step 1601, messaging server 308 periodically polls the user'svoicemail server 312 over the public IP network 306. In particularembodiments, mailbox server 308 transmits the authentication credentialsalong with this request. In particular embodiments, mailbox server pollsvoicemail server 312 at predetermined intervals, such as, for example,30 minutes. In particular embodiments, the user may set thepredetermined interval. This disclosure contemplates any suitable methodof polling voicemail server 312 from mailbox server 308. In particularembodiments, messaging server 308 may utilize both polling of voicemailserver 312 as well as receiving messages from client device 140. Inparticular embodiments, voicemail server 312 may push notifications toclient device 140 between polls, as discussed in further detail withreference to Step 1600. Utilizing both polling and client notificationensures that messaging server 308 receives a new message notification assoon as a new message arrives.

At Step 1602, voicemail server 312 responds, after authenticating thatmailbox server 308 has access to the user's voice mailbox, that thereare one or more new voicemails in the user's voice mailbox. Additionallyat Step 1602, mailbox server 308 downloads the new voicemails overpublic IP network 306. In particular embodiments, voicemail servers 312,312A may be unconnected to the public IP network 306, that is, they maybe part of a carrier intranet. In such embodiments, a specializednetwork gateway may be installed between mailbox server 308 andvoicemail server 312. This disclosure contemplates any suitable methodof integrating with external voicemail servers, regardless of whetherthe servers are hosted on private intranet, behind corporate firewalls,etc.

At Step 1603, mailbox server 308 stores the new voicemail or voicemailsin the user's mailbox 160. In particular embodiments, the voicemail isan audio file that may be downloaded and played either at mobile device140 or over web interface 150. In particular embodiments, the voicemailis a link to an audio file stored on an external server. In particularembodiments, mailbox server 308 performs speech-to-text transcription,and the voicemail is stored as a text transcript. This disclosurecontemplates any suitable method of storing or processing voicemailsdownloaded from the user's carrier voice mailbox.

At Step 1604, mailbox server 308 delivers the voicemail to mobile device140. Mailbox server 308 may utilize any delivery channel, either datachannel 312 a or SMS channel 312B, to deliver the voicemail. Asdescribed above, the voicemail may be delivered as an audio file, a linkto an audio file, or a text transcription of the voicemail. Inparticular embodiments, where the voicemail is delivered to mobiledevice 140 via SMS channel 312B, the voicemail is delivered as a texttranscription, or an MMS message. MMS messages are well-known in the artand will not be further discussed here.

The method of Steps 1601 through 1604 permits users to access theirvoicemail at any time, even when their device lacks a connection totheir carrier voice mailbox server. For example, a user traveling on aplane will generally shut off his or her mobile device due to federalregulations or lack of connectivity. If the user is on a flight offeringin-flight WiFi, the user may still access his or her voicemail throughweb interface 150. Thus the user may still check and receive voicemailseven when mobile device 140 has no connectivity.

In particular embodiments, new message notifications may be pushed viaan SMS channel or other communications channel directly from voicemailserver 312 to messaging server 308. For example, when a new messagearrives at voicemail server 312, voicemail server 312 may transmit anotification, either as an SMS or data packet, to messaging server 308immediately upon reception of the voicemail at Step 1600. In response,mailbox server 308 may, at Step 1601, issue a “synchronize” or “sync”request to voicemail server 312, requesting that any new messages betransmitted to mailbox server 308. In such embodiments, after the synchrequest is processed by voicemail server 312, the message is pushed downin Step 1602 as previously discussed.

In particular scenarios, carrier voicemail servers 312, 312A are notconnected to the public IP network, and are unwilling to install aconnection from their voice mailbox servers to mailbox server 308. Insuch situations, mobile device 140 first pulls down the voicemail fromits voice mailbox server 312 and then transmits it to mailbox server308.

At Step 1601′, mobile device 140 polls voicemail server 312 for newmessages. In particular embodiments, the messaging client applicationprovides authentication credentials to the voicemail server 312. Inparticular embodiments, voicemail server 312 transmits a notification tomobile device 140 a when a new message has arrived. Such implementationsare carrier-specific and will not be discussed further here. Thisdisclosure contemplates any suitable method of checking for new messageat a voicemail server. At Step 1602′, voicemail server 312 notifiesmobile device 140 that there are one or more new voicemails in theuser's voice mailbox, and transmits the voicemail to the user. At thispoint, the user may listen to the voicemail on his or her mobile device140.

At Step 1603′, the messaging client on mobile device 140 transmits thevoicemail to mailbox server 308 and requests its storage in the user'smailbox 160. At Step 1604′, mailbox server 308 stores the message in theuser's mailbox 160, and performs any necessary processing ortranscription as previously described.

As previously described with regard to step 1600; voicemail server 312may utilize a “push-synchronize” model rather than the “poll-pull” modelas depicted in FIG. 16. For example, upon receiving a new voicemail forthe user account associated with mobile device 140, voicemail server 312may transmit a push notification to mobile device 140 that a new messagehas arrived. As discussed, the push notification may, in particularembodiments, be transmitted through an SMS channel, or other persistentTCP/IP connection. In response, mobile device 140 may issue asynchronize request to mailbox server 312, which in turn transmits thenew message to mobile device 140. This disclosure contemplates anysuitable mechanism of informing mobile device 140 of new messages, andany method of delivery of the new messages.

While the foregoing embodiments may be implemented in a variety ofnetwork configurations, the following illustrates an example networkenvironment for didactic, and not limiting, purposes. FIG. 17illustrates an example network environment 1700. Network environment1700 includes a network 1710 coupling one or more servers 1720 and oneor more clients 1730 to each other. Network environment 1700 alsoincludes one or more data storage 1740 linked to one or more servers1720. Particular embodiments may be implemented in network environment1700. For example, social networking system frontend 120 may be writtenin software programs hosted by one or more servers 1720. For example,event database 102 may be stored in one or more storage 1740. Inparticular embodiments, network 1710 is an intranet, an extranet, avirtual private network (VPN), a local area network (LAN), a wirelessLAN (WLAN), a wide area network (WAN), a metropolitan area network(MAN), a portion of the Internet, or another network 1710 or acombination of two or more such networks 1710. The present disclosurecontemplates any suitable network 1710.

One or more links 1750 couple a server 1720 or a client 1730 to network1710. In particular embodiments, one or more links 1750 each includesone or more wired, wireless, or optical links 1750. In particularembodiments, one or more links 1750 each includes an intranet, anextranet, a VPN, a LAN, a WLAN, a WAN, a MAN, a portion of the Internet,or another link 1750 or a combination of two or more such links 1750.The present disclosure contemplates any suitable links 1750 couplingservers 1720 and clients 1730 to network 1710.

In particular embodiments, each server 1720 may be a unitary server ormay be a distributed server spanning multiple computers or multipledatacenters. Servers 1720 may be of various types, such as, for exampleand without limitation, web server, news server, mail server, messageserver, advertising server, file server, application server, exchangeserver, database server, or proxy server. In particular embodiments,each server 1720 may include hardware, software, or embedded logiccomponents or a combination of two or more such components for carryingout the appropriate functionalities implemented or supported by server1720. For example, a web server is generally capable of hosting websitescontaining web pages or particular elements of web pages. Morespecifically, a web server may host HTML files or other file types, ormay dynamically create or constitute files upon a request, andcommunicate them to clients 1730 in response to HTTP or other requestsfrom clients 1730. A mail server is generally capable of providingelectronic mail services to various clients 1730. A database server isgenerally capable of providing an interface for managing data stored inone or more data stores.

In particular embodiments, one or more data storages 1740 may becommunicatively linked to one or more servers 1720 via one or more links1750. In particular embodiments, data storages 1740 may be used to storevarious types of information. In particular embodiments, the informationstored in data storages 1740 may be organized according to specific datastructures. In particular embodiment, each data storage 1740 may be arelational database. Particular embodiments may provide interfaces thatenable servers 1720 or clients 1730 to manage, e.g., retrieve, modify,add, or delete, the information stored in data storage 1740.

In particular embodiments, each client 1730 may be an electronic deviceincluding hardware, software, or embedded logic components or acombination of two or more such components and capable of carrying outthe appropriate functions implemented or supported by client 1730. Forexample and without limitation, a client 1730 may be a desktop computersystem, a notebook computer system, a netbook computer system, ahandheld electronic device, or a mobile telephone. The presentdisclosure contemplates any suitable clients 1730. A client 1730 mayenable a network user at client 1730 to access network 1730. A client1730 may enable its user to communicate with other users at otherclients 1730.

A client 1730 may have a web browser 1732, such as MICROSOFT INTERNETEXPLORER, GOOGLE CHROME or MOZILLA FIREFOX, and may have one or moreadd-ons, plug-ins, or other extensions, such as TOOLBAR or YAHOOTOOLBAR. A user at client 1730 may enter a Uniform Resource Locator(URL) or other address directing the web browser 1732 to a server 1720,and the web browser 1732 may generate a Hyper Text Transfer Protocol(HTTP) request and communicate the HTTP request to server 1720. Server1720 may accept the HTTP request and communicate to client 1730 one ormore Hyper Text Markup Language (HTML) files responsive to the HTTPrequest. Client 1730 may render a web page based on the HTML files fromserver 1720 for presentation to the user. The present disclosurecontemplates any suitable web page files. As an example and not by wayof limitation, web pages may render from HTML files, Extensible HyperText Markup Language (XHTML) files, or Extensible Markup Language (XML)files, according to particular needs. Such pages may also executescripts such as, for example and without limitation, those written inJAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, combinations of markup languageand scripts such as AJAX (Asynchronous JAVASCRIPT and XML), and thelike. Herein, reference to a web page encompasses one or morecorresponding web page files (which a browser may use to render the webpage) and vice versa, where appropriate.

FIG. 18 illustrates an example computer system 1800, which may be usedwith some embodiments. This disclosure contemplates any suitable numberof computer systems 1800. This disclosure contemplates computer system1800 taking any suitable physical form. As example and not by way oflimitation, computer system 1800 may be an embedded computer system, asystem-on-chip (SOC), a single-board computer system (SBC) (such as, forexample, a computer-on-module (COM) or system-on-module (SOM)), adesktop computer system, a laptop or notebook computer system, aninteractive kiosk, a mainframe, a mesh of computer systems, a mobiletelephone, a personal digital assistant (PDA), a server, or acombination of two or more of these. Where appropriate, computer system1800 may include one or more computer systems 1800; be unitary ordistributed; span multiple locations; span multiple machines; or residein a cloud, which may include one or more cloud components in one ormore networks. Where appropriate, one or more computer systems 1800 mayperform without substantial spatial or temporal limitation one or moresteps of one or more methods described or illustrated herein. As anexample and not by way of limitation, one or more computer systems 1800may perform in real time or in batch mode one or more steps of one ormore methods described or illustrated herein. One or more computersystems 1800 may perform at different times or at different locationsone or more steps of one or more methods described or illustratedherein, where appropriate.

In particular embodiments, computer system 1800 includes a processor1802, memory 1804, storage 1806, an input/output (I/O) interface 1808, acommunication interface 1810, and a bus 1812. Although this disclosuredescribes and illustrates a particular computer system having aparticular number of particular components in a particular arrangement,this disclosure contemplates any suitable computer system having anysuitable number of any suitable components in any suitable arrangement.

In particular embodiments, processor 1802 includes hardware forexecuting instructions, such as those making up a computer program. Asan example and not by way of limitation, to execute instructions,processor 1802 may retrieve (or fetch) the instructions from an internalregister, an internal cache, memory 1804, or storage 1806; decode andexecute them; and then write one or more results to an internalregister, an internal cache, memory 1804, or storage 1806. In particularembodiments, processor 1802 may include one or more internal caches fordata, instructions, or addresses. The present disclosure contemplatesprocessor 1802 including any suitable number of any suitable internalcaches, where appropriate. As an example and not by way of limitation,processor 1802 may include one or more instruction caches, one or moredata caches, and one or more translation look-aside buffers (TLBs).Instructions in the instruction caches may be copies of instructions inmemory 1804 or storage 1806, and the instruction caches may speed upretrieval of those instructions by processor 1802. Data in the datacaches may be copies of data in memory 1804 or storage 1806 forinstructions executing at processor 1802 to operate on; the results ofprevious instructions executed at processor 1802 for access bysubsequent instructions executing at processor 1802 or for writing tomemory 1804 or storage 1806; or other suitable data. The data caches mayspeed up read or write operations by processor 1802. The TLBs may speedup virtual-address translation for processor 1802. In particularembodiments, processor 1802 may include one or more internal registersfor data, instructions, or addresses. The present disclosurecontemplates processor 1802 including any suitable number of anysuitable internal registers, where appropriate. Where appropriate,processor 1802 may include one or more arithmetic logic units (ALUs); bea multi-core processor; or include one or more processors 1802. Althoughthis disclosure describes and illustrates a particular processor, thisdisclosure contemplates any suitable processor.

In particular embodiments, memory 1804 includes main memory for storinginstructions for processor 1802 to execute or data for processor 1802 tooperate on. As an example and not by way of limitation, computer system1800 may load instructions from storage 1806 or another source (such as,for example, another computer system 1800) to memory 1804. Processor1802 may then load the instructions from memory 1804 to an internalregister or internal cache. To execute the instructions, processor 1802may retrieve the instructions from the internal register or internalcache and decode them. During or after execution of the instructions,processor 1802 may write one or more results (which may be intermediateor final results) to the internal register or internal cache. Processor1802 may then write one or more of those results to memory 1804. Inparticular embodiments, processor 1802 executes only instructions in oneor more internal registers or internal caches or in memory 1804 (asopposed to storage 1806 or elsewhere) and operates only on data in oneor more internal registers or internal caches or in memory 1804 (asopposed to storage 1806 or elsewhere). One or more memory buses (whichmay each include an address bus and a data bus) may couple processor1802 to memory 1804. Bus 1812 may include one or more memory buses, asdescribed below. In particular embodiments, one or more memorymanagement units (MMUs) reside between processor 1802 and memory 1804and facilitate accesses to memory 1804 requested by processor 1802. Inparticular embodiments, memory 1804 includes random access memory (RAM).This RAM may be volatile memory, where appropriate Where appropriate,this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, whereappropriate, this RAM may be single-ported or multi-ported RAM. Thepresent disclosure contemplates any suitable RAM. Memory 1804 mayinclude one or more memories 1802, where appropriate. Although thisdisclosure describes and illustrates particular memory, this disclosurecontemplates any suitable memory.

In particular embodiments, storage 1806 includes mass storage for dataor instructions. As an example and not by way of limitation, storage1806 may include an HDD, a floppy disk drive, flash memory, an opticaldisc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus(USB) drive or a combination of two or more of these. Storage 1806 mayinclude removable or non-removable (or fixed) media, where appropriate.Storage 1806 may be internal or external to computer system 1800, whereappropriate. In particular embodiments, storage 1806 is non-volatile,solid-state memory. In particular embodiments, storage 1806 includesread-only memory (ROM). Where appropriate, this ROM may bemask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM),electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM),or flash memory or a combination of two or more of these. Thisdisclosure contemplates mass storage 1806 taking any suitable physicalform. Storage 1806 may include one or more storage control unitsfacilitating communication between processor 1802 and storage 1806,where appropriate. Where appropriate, storage 1806 may include one ormore storages 1806. Although this disclosure describes and illustratesparticular storage, this disclosure contemplates any suitable storage.

In particular embodiments, I/O interface 1808 includes hardware,software, or both providing one or more interfaces for communicationbetween computer system 1800 and one or more I/O devices. Computersystem 1800 may include one or more of these I/O devices, whereappropriate. One or more of these I/O devices may enable communicationbetween a person and computer system 1800. As an example and not by wayof limitation, an I/O device may include a keyboard, keypad, microphone,monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet,touch screen, trackball, video camera, another suitable I/O device or acombination of two or more of these. An I/O device may include one ormore sensors. This disclosure contemplates any suitable I/O devices andany suitable I/O interfaces 1808 for them. Where appropriate, I/Ointerface 1808 may include one or more device or software driversenabling processor 1802 to drive one or more of these I/O devices. I/Ointerface 1808 may include one or more I/O interfaces 1808, whereappropriate. Although this disclosure describes and illustrates aparticular I/O interface, this disclosure contemplates any suitable I/Ointerface.

In particular embodiments, communication interface 1810 includeshardware, software, or both providing one or more interfaces forcommunication (such as, for example, packet-based communication) betweencomputer system 1800 and one or more other computer systems 1800 or oneor more networks. As an example and not by way of limitation,communication interface 1810 may include a network interface controller(NIC) or network adapter for communicating with an Ethernet or otherwire-based network or a wireless NIC (WNIC) or wireless adapter forcommunicating with a wireless network, such as a WI-FI network. Thisdisclosure contemplates any suitable network and any suitablecommunication interface 1810 for it. As an example and not by way oflimitation, computer system 1800 may communicate with an ad hoc network,a personal area network (PAN), a local area network (LAN), a wide areanetwork (WAN), a metropolitan area network (MAN), or one or moreportions of the Internet or a combination of two or more of these. Oneor more portions of one or more of these networks may be wired orwireless. As an example, computer system 1800 may communicate with awireless PAN (WPAN) (such as, for example, a BLUETOOTH WPAN), a WI-FInetwork, a WI-MAX network, a cellular telephone network (such as, forexample, a Global System for Mobile Communications (GSM) network), orother suitable wireless network or a combination of two or more ofthese. Computer system 1800 may include any suitable communicationinterface 1810 for any of these networks, where appropriate.Communication interface 1810 may include one or more communicationinterfaces 1810, where appropriate. Although this disclosure describesand illustrates a particular communication interface, this disclosurecontemplates any suitable communication interface.

In particular embodiments, bus 1812 includes hardware, software, or bothcoupling components of computer system 1800 to each other. As an exampleand not by way of limitation, bus 1812 may include an AcceleratedGraphics Port (AGP) or other graphics bus, an Enhanced Industry StandardArchitecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPORT (HT)interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBANDinterconnect, a low-pin-count (LPC) bus, a memory bus, a Micro ChannelArchitecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, aPCI-Express (PCI-X) bus, a serial advanced technology attachment (SATA)bus, a Video Electronics Standards Association local (VLB) bus, oranother suitable bus or a combination of two or more of these. Bus 1812may include one or more buses 1812, where appropriate. Although thisdisclosure describes and illustrates a particular bus, this disclosurecontemplates any suitable bus or interconnect.

Herein, reference to a computer-readable non-transitory storage mediummay include a semiconductor-based or other integrated circuit (IC) (suchas, for example, a field-programmable gate array (FPGA) or anapplication-specific IC (ASIC)), a hard disk drive (HDD), a hybrid harddrive (HHD), an optical disc, an optical disc drive (ODD), amagneto-optical disc, a magneto-optical drive, a floppy disk, a floppydisk drive (FDD), magnetic tape, a holographic storage medium, asolid-state drive (SSD), a RAM-drive, a SECURE DIGITAL card, a SECUREDIGITAL drive, another suitable computer-readable non-transitory storagemedium, or a suitable combination of these, where appropriate. Acomputer-readable non-transitory storage medium may be volatile,non-volatile, or a combination of volatile and non-volatile, whereappropriate. This disclosure contemplates one or more computer-readablestorage media implementing any suitable storage. In particularembodiments, a computer-readable storage medium implements one or moreportions of processor 1802 (such as, for example, one or more internalregisters or caches), one or more portions of memory 1804, one or moreportions of storage 606, or a combination of these, where appropriate.In particular embodiments, a computer-readable storage medium implementsRAM or ROM. In particular embodiments, a computer-readable storagemedium implements volatile or persistent memory. In particularembodiments, one or more computer-readable storage media embodysoftware. Herein, reference to software may encompass one or moreapplications, bytecode, one or more computer programs, one or moreexecutables, one or more instructions, logic, machine code, one or morescripts, or source code, and vice versa, where appropriate. Inparticular embodiments, software includes one or more applicationprogramming interfaces (APIs). This disclosure contemplates any suitablesoftware written or otherwise expressed in any suitable programminglanguage or combination of programming languages. In particularembodiments, software is expressed as source code or object code. Inparticular embodiments, software is expressed in a higher-levelprogramming language, such as, for example, C, Perl, or a suitableextension thereof. In particular embodiments, software is expressed in alower-level programming language, such as assembly language (or machinecode). In particular embodiments, software is expressed in JAVA. Inparticular embodiments, software is expressed in Hyper Text MarkupLanguage (HTML), Extensible Markup Language (XML), or other suitablemarkup language.

The present disclosure encompasses all changes, substitutions,variations, alterations, and modifications to the example embodimentsherein that a person having ordinary skill in the art would comprehend.Similarly, where appropriate, the appended claims encompass all changes,substitutions, variations, alterations, and modifications to the exampleembodiments herein that a person having ordinary skill in the art wouldcomprehend.

The foregoing description of the embodiments has been presented for thepurpose of illustration; it is not intended to be exhaustive or to limitthe disclosure to the precise forms disclosed. Persons skilled in therelevant art can appreciate that many modifications and variations arepossible in light of the above disclosure. For example, although theforegoing embodiments have been described in the context of a socialnetwork system, it will apparent to one of ordinary skill in the artthat this disclosure may be used with any electronic social networkservice and, even if it is not provided through a website. Anycomputer-based system that provides social networking functionality canbe used even if it relies, for example, on e-mail, instant messaging orother form of peer-to-peer communications, and any other technique forcommunicating between users. This disclosure is thus not limited to anyparticular type of communication system, network, protocol, format orapplication.

Some portions of this description describe the embodiments in terms ofalgorithms and symbolic representations of operations on information.These algorithmic descriptions and representations are commonly used bythose skilled in the data processing arts to convey the substance oftheir work effectively to others skilled in the art. These operations,while described functionally, computationally, or logically, areunderstood to be implemented by computer programs or equivalentelectrical circuits, microcode, or the like. Furthermore, it has alsoproven convenient at times, to refer to these arrangements of operationsas modules, without loss of generality. The described operations andtheir associated modules may be embodied in software, firmware,hardware, or any combinations thereof.

Any of the steps, operations, or processes described herein may beperformed or implemented with one or more hardware or software modules,alone or in combination with other devices. In one embodiment, asoftware module is implemented with a computer program productcomprising a computer-readable medium containing computer program code,which can be executed by a computer processor for performing any or allof the steps, operations, or processes described.

Particular embodiments may also relate to an apparatus for performingthe operations herein. This apparatus may be specially constructed forthe required purposes, and/or it may comprise a general-purposecomputing device selectively activated or reconfigured by a computerprogram stored in the computer. Such a computer program may be stored ina tangible computer readable storage medium or any type of mediasuitable for storing electronic instructions, and coupled to a computersystem bus. Furthermore, any computing systems referred to in thespecification may include a single processor or may be architecturesemploying multiple processor designs for increased computing capability.

While the foregoing processes and mechanisms can be implemented by awide variety of physical systems and in a wide variety of network andcomputing environments, the server or computing systems described belowprovide example computing system architectures for didactic, rather thanlimiting, purposes.

The present application has been explained with reference to specificembodiments. For example, while particular embodiments have beendescribed as operating in connection with a social network system,particular embodiments can be used in connection with any communicationsfacility that allows for communication of messages between users, suchas an email hosting site. Other embodiments will be evident to those ofordinary skill in the art. It is therefore not intended that the presentdisclosure be limited, except as indicated by the appended claims.

Finally, the language used in the specification has been principallyselected for readability and instructional purposes, and it may not havebeen selected to delineate or circumscribe the inventive subject matter.It is therefore intended that the scope of the invention be limited notby this detailed description, but rather by any claims that issue on anapplication based hereon. Accordingly, the disclosure of the embodimentsof the invention is intended to be illustrative, but not limiting, ofthe scope of the invention, which is set forth in the following claims.

What is claimed is:
 1. A method comprising: by one or more computingdevices of a social-networking system, receiving, from a first client ofone or more clients associated with a first node in a social graph ofthe social-networking system, a first communication between the firstclient and a plurality of other clients, the first communicationassociated with a first protocol and comprising identifiers for theplurality of other clients; by the one or more computing devices of thesocial-networking system, searching a database of threads maintained bythe social-networking system, each thread comprising a plurality ofparticipants, for a matching thread associated with the first node andhaving a plurality of participants matching the identifiers for theplurality of other clients, wherein each of the participants isrepresented by a second node in the social graph, wherein the first nodeis connected through the social graph to each of the second nodes, andwherein the social graph describes social relationships between thefirst node and each of the second nodes, the social relationships basedon shared connections between the first node and each of the secondnodes; by the one or more computing devices of the social-networkingsystem, if a matching thread is identified, then adding informationassociated with the first communication to the matching thread; by theone or more computing devices of the social-networking system, if amatching thread is not identified, then creating a new thread associatedwith the first node, the new thread comprising the informationassociated with the first communication; by the one or more computingdevices of the social-networking system, for each of the second nodes:sending, through a first communication channel, to a mailbox server, arequest for a message-delivery policy of the second node; selecting acommunication channel from a plurality of communication channels basedon the message-delivery policy of the second node, wherein the pluralityof communication channels comprise the first communication channel and asecond communication channel; if the message-delivery policy indicatesthat the communication is to be sent using the first channel, thensending, to the mailbox server, the communication; if themessage-delivery policy indicates that the communication is to be sentusing the second communication channel, then requesting a carrier SMSserver to send, to a second client associated with the second node, thecommunication through the second communication channel in an SMSmessage; and sending the first communication through the selectedcommunication protocol channel for the second node; and requesting,using the first communication channel, the mailbox server to store thefirst communication in a mailbox associated with the second node; by theone or more computing devices of the social-networking system, receivinga second communication between one of the one or more clients associatedwith the first node and the plurality of other clients, the secondcommunication associated with a second protocol, different from thefirst protocol, and comprising identifiers for the plurality of otherclients; and by the one or more computing devices of thesocial-networking system, adding information associated with the secondcommunication to the matching thread or the new thread.
 2. The method ofclaim 1, wherein the identifiers are social networking user identifiers,each associated with a node in the social graph.
 3. The method of claim1, wherein the identifiers are received from the client as phonenumbers, and further comprising: performing, prior to searching thedatabase of threads, a reverse-lookup for each phone number in adatabase of phone numbers, each number in the database of phone numbersassociated with a social networking user identifier representing a nodeon a social networking system; and replacing, for each phone numberhaving an associated social networking user identifier, the identifierwith the social networking identifier; and for each phone number nothaving an associated social networking user identifier, adding the phonenumber to the database of phone numbers.
 4. The method of claim 1,wherein the identifiers are received as phone numbers, and furthercomprising: performing a reverse-lookup for each phone number in adatabase of phone numbers, each number in the database of phone numbersassociated with a social networking user identifier representing a nodeon a social networking system; and replacing, for each phone numberhaving an associated social networking user identifier, the identifierwith the social networking identifier; and for each phone number nothaving an associated social networking user identifier, adding the phonenumber to the database of phone numbers.
 5. The method of claim 1,wherein the first communication is a voice call, and the informationassociated with the first communication comprises a time and date of thevoice call.
 6. The method of claim 1, wherein the first communication isa text message, and the information associated with the firstcommunication comprises: a time and date of the text message; a senderand one or more recipients of the text message; and text of the textmessage.
 7. The method of claim 1, wherein the first communication is avoicemail, and the information associated with the first communicationcomprises: a time and date of the voicemail; a sender and recipient ofthe voicemail; and content of the voicemail.
 8. The method of claim 7,wherein the content of the voicemail comprises an audio recording of thevoicemail.
 9. The method of claim 7, wherein the content of thevoicemail comprises a link to an audio recording of the voicemail. 10.The method of claim 7, wherein the content of the voicemail comprises aseries of text strings obtained through speech-to-text processing of thevoicemail.
 11. The method of claim 1, wherein the first protocolcomprises one or more of the following: voice over IP; acircuit-switched network protocol; a packet data network protocol; acellular network protocol; a WIFI protocol; a notification channel; oran SMS channel.
 12. A system comprising: one or more processors; and amemory coupled to the processors comprising instructions executable bythe processors, the processors operable when executing the instructionsto: at one or more computing devices of the social-networking system,receive, from a first client of one or more clients associated with afirst node in a social graph of the social-networking system, a firstcommunication between the first client and a plurality of other clients,the first communication associated with a first protocol and comprisingidentifiers for the plurality of other clients; at one or more computingdevices of the social-networking system, search a database of threadsmaintained by the social-networking system, each thread comprising aplurality of participants, for a matching thread associated with thefirst node and having a plurality of participants matching theidentifiers for the plurality of other clients, wherein each of theparticipants is represented by a second node in the social graph,wherein the first node is connected through the social graph to each ofthe second nodes, and wherein the social graph describes socialrelationships between the first node and each second node, the socialrelationships based on shared connections between the first node andeach second node; if a matching thread is identified, then, at one ormore computing devices of the social-networking system, add informationassociated with the first communication to the matching thread; if amatching thread is not identified, then, at one or more computingdevices of the social-networking system, create a new thread associatedwith the first node, the new thread comprising the informationassociated with the first communication; at one or more computingdevices of the social-networking system, for each of the second nodes:sending, through a first communication channel, to a mailbox server, arequest for a message-delivery policy of the second node; selecting acommunication channel from a plurality of communication channels basedon the message-delivery policy of the second node, wherein the pluralityof communication channels comprise the first communication channel and asecond communication channel; if the message-delivery policy indicatesthat the communication is to be sent using the first channel, thensending, to the mailbox server, the communication; if themessage-delivery policy indicates that the communication is to be sentusing the second communication channel, then requesting a carrier SMSserver to send, to a second client associated with the second node, thecommunication through the second communication channel in an SMSmessage; and sending the first communication through the selectedcommunication protocol channel for the second node; and requesting,using the first communication channel, the mailbox server to store thefirst communication in a mailbox associated with the second node; at oneor more computing devices of the social-networking system, receive asecond communication between one of the one or more clients associatedwith the first node and the plurality of other clients, the secondcommunication associated with a second protocol, different from thefirst protocol, and comprising identifiers for the plurality of otherclients; and at one or more computing devices of the social-networkingsystem, add information associated with the second communication to thematching thread or the new thread.
 13. The system of claim 12, whereinthe identifiers are social networking user identifiers, each associatedwith a node in the social graph.
 14. The system of claim 12, wherein thefirst communication is a voice call, and the information associated withthe first communication comprises a time and date of the voice call. 15.The system of claim 12, wherein the first communication is a textmessage, and the information associated with the first communicationcomprises: a time and date of the text message; a sender and one or morerecipients of the text message; and text of the text message.
 16. Thesystem of claim 12, wherein the first communication is a voicemail, andthe information associated with the first communication comprises: atime and date of the voicemail; a sender and recipient of the voicemail;and content of the voicemail.
 17. The system of claim 16, wherein thecontent of the voicemail comprises an audio recording of the voicemail.18. The system of claim 16, wherein the content of the voicemailcomprises a link to an audio recording of the voicemail.
 19. The systemof claim 16, wherein the content of the voicemail comprises a series oftext strings obtained through speech-to-text processing of thevoicemail.
 20. The system of claim 12, wherein the first protocolcomprises one or more of the following: voice over IP; acircuit-switched network protocol; a packet data network protocol; acellular network protocol; a WIFI protocol; a notification channel; oran SMS channel.